The present invention relates to methods and devices for key management in an as-a-service (aaS) context (e.g., SaaS (software as a service), PaaS (platform as a service), and IaaS (infrastructure as a service)).
Key-management processes involving splitting keys are well-established. All data-encryption keys are split using a master key. The master key is: (1) a real key, not a password; (2) known (i.e., revealed) only to the customer; and (3) very easy to manage. Keys are encrypted and integrity-protected using standard algorithms. Keys are associated with (encrypted and integrity-protected) metadata. Customer-side key hierarchies provide deployment flexibility.
Assume that a key may be legitimately used by several entities in an environment (each is called an “appliance”); some of the appliances may create the key, while other appliances may use the key. Each such creation operation or usage operation may in principal be performed by the same or a different entity.
Also, the appliances are in communication with a Protected Virtual Key Manager (PVKM) which may provide services to the abovementioned appliances and to the users of the system. Such services are related to managing the keys of the system, and also related to enhancing the security of the system.
In the discussion below, the PVKM may be viewed as a “location” (whether physical or virtual) in such an environment, while each appliance and other security element may be viewed as another “location” (whether physical or virtual). However, for the avoidance of doubt, while the PVKM itself may be implemented as a collection or a cluster, it is still referred to as a location for the sake of simplicity.
Referring to the drawings, the overall processes have been depicted according to separate, sequential time lines (going from top to bottom in the drawings) for two primary generalized components, an appliance A and a PVKM B, in order to representationally isolate the parallel processes that are occurring on each component independently.
FIG. 1 is a simplified high-level block diagram of the scheme of major operational steps in an exemplary implementation for splitting keys in a key-management system, according to the prior art. To split key-pairs (Sub-Process I), an appliance A and a PVKM B are shown in which PVKM B generates an appropriate key-pair (Block Step 2), and transmits a half-key to appliance A (Arrow Step 4). Appliance A then uses the half-key with a master key (Block Step 6) to create a data encryption key (Block Step 8).
It is noted that appliance A is intended to be a simplified example of a plurality of appliances in order to provide clarity throughout the description. It is understood that the present invention has broader applicability to a collection or cluster of such appliances. Furthermore, PVKM B is intended to be one conceptual entity (e.g., a server); however, in practical implementations, PVKM B may be a plurality of entities (e.g., a cluster of servers for fail-over protection). In generalizations of this approach, there may be more locations, and therefore more timelines.
The master key is critical to the security of the whole system. Initially, it is kept only in memory. A passive attacker that takes a “snapshot” of the storage device cannot see the master key. The master key is then encrypted so that even an active attack is mitigated. Such encryption is access-controlled, policed on the key-management service, and integrated with customer access-control.
In order to encrypt the key, and yet still use the key, Homomorphic Key Management (HKM) has been shown to be an effective protocol. Homomorphic functions have F(a⊖b)=F(a)⊖F(b) in which ⊖ is a suitable operator. Partially-homomorphic functions are employed for key management only (e.g., ElGamal encryption).
ElGamal encryption is homomorphic and entails a secret key x and a public key (g, h=gx) in which g is a generator. Encryption is random and produces a pair: Enc(m)=(c, d)=(gr, hr·m) in which r is random, and Dec(c, d)=d/cx=m. Such keys can be used to exploit the homomorphic property. As an example, under a multiplication operation: Encpk(m; r)Encpk(m′; r′)=Encpk(m·m′; r+r′) for element-wise multiplication. Such HKM methods employing split-key encryption are amenable to exact proofs of strength.
FIG. 2 is a simplified high-level block diagram of the scheme of major operational steps in an exemplary implementation for creating an appliance using homomorphic key-management, according to the prior art. To create a new appliance using HKM (Sub-Process II), PVKM B picks an ElGamal key (Block Step 10), stores a secret half-key, SKi (Block Step 12), and transmits a public half-key, PKi, to appliance A (Arrow Step 14), which stores PKi (Block Step 16). Appliance A uses PKi to encrypt a user-supplied master-key K as EPKi(K) (Block Step 18). Appliance A then generates and stores a random mask, masks (Block Step 20). Appliance A performs a homomorphic operation by calculating EPKi(K⊖maski) (Block Step 22), and transmits the result to PVKM B (Arrow Step 24), which then decrypts and stores the masked master-key, (K⊖maski) (Block Step 26). It is denoted that ⊖ is a suitable operator for encryption; the inverse of ⊖ is denoted as “/” (sometimes represented by the symbol “÷”) for decryption.
FIG. 3 is a simplified high-level block diagram of the scheme of major operational steps in an exemplary implementation for creating a new key using homomorphic key-management, according to the prior art. To create a new key using HKM (Sub-Process III), appliance A creates a request to generate a new key, ki (Block Step 30), and transmits the key request to PVKM B (Arrow Step 32). PVKM B picks and stores a random number, ai (Block Step 34), and then calculates bij=aj/(K⊖maski) (Block Step 36), which is then transmitted to appliance A (Arrow Step 38). Appliance A then uses the result to calculate a specific key, Sj=bij⊖maski=aj/K (Block Step 40). It is noted that Sj is independent of i (i.e., common to all appliances with the same master-key, K).
As mentioned, the master key is known (i.e., revealed) only to the customer. However, in “as-a-Service” use-cases, there are actually a chain of customers. For example, one customer of the key-management mechanisms may be a service provider, which may know the master key. However, “end” customers further down the chain may be customers of the service provider. A security-conscious end-customer desires to be able to use available shared or distributed resources in the aaS context configured for a multi-tenant environment, as provided by the service provider, and yet enjoy full security and control—by controlling their own keys in such a way that the service provider knows nothing about the keys.
It would be desirable to have methods and devices methods and devices for key management in an as-a-service (aaS) distributed environment. Such methods and devices would, inter alia, expand on the capabilities and applications of the methods mentioned above.